Network traffic management aims to cost-effectively minimize the number of unsuccessful communication attempts caused by network congestion or failure, while also ensuring that expensive network equipment is not over- or under-used. The ultimate goal is to provide a given grade of service with the least amount of equipment. To do this, one must determine the amount of traffic handled by the network, particularly by switches in the network. Traffic data describes the amount and features of the communications (voice, video or data) traffic through the network. It is collected to help operators of communication networks determine how efficiently those networks are operating and, if necessary, to plan network reductions, repairs or upgrades. By way of example, determining that congestion generated "fast busy" signals for over 2% of communications attempted through a particular switch at selected time periods tells network engineers (a) to expect customer complaints about poor service and (b) that the network may need a repair or an upgrade if the problem persists.
Traffic data also is helpful to large customers who rent or lease network facilities. The owner of this invention also owns a patent that describes a "Telephone System Adapted to Report to Customers Telephone Facility Traffic Data." That U.S. Pat. No. 5,410,589, which describes the advantages of and procedures for collecting and reporting traffic data, is hereby incorporated in its entirety by this reference.
Typically, the enormous volume and types of traffic across network switches allowed collection and analysis of only statistically significant samples of traffic data, rather than collecting and analyzing traffic in real time. Thus, prior methods of analyzing switch traffic use the "average peak usage hour" for the entire switch. Peak usage or busy hour refers to the hour of the day in which traffic across the switch hits a peak (although the phrase uses the term "hour," the peak usage can be determined over any time period). The "average" refers to the fact that the average peak usage hour is selected by averaging the traffic across many days and then determining the hour of the day during which peak usage of the network switch occurs. Generally, the average peak usage hour has been determined once per year by manually analyzing the switch traffic usage. The selected "average peak usage hour" is then used for network traffic engineering for the remainder of the year, with switches engineered to handle the volume and type of traffic that occurs during their average peak usage hour.
For example, commercial systems like the COER system marketed by Lucent Technologies, Inc. (formerly part of AT&T) take traffic data from a particular switch and then organize and report that data to allow engineers manually to determine whether switch limits have been reached. This required that the traffic analysis process involve only a small subset of the available data. Also, the COER system determined busy hour only once a year and only for the whole switch.
Other efforts at traffic monitoring have been made. For instance, U.S. Pat. No. 4,456,788 to Kline, et al. describes a "Telecommunication Trunk Circuit Reporter and Advisor" system and method that analyses trunk circuit data. The Kline, et al. patent mentions determining busy hours, but does not describe doing so on a switch component or continuous basis. U.S. Pat. No. 5,359,649 describes systems for "Congestion Tuning of Telecommunications Networks" that monitor network elements and routes to identify congested routes and repair them or reroute traffic.
These prior processes and systems do not address several problems, however. First, a certain number of switch components are engineered beyond (or below) their capacity. That is because traffic data has been collected only for the average peak usage hour of the entire switch, which means that traffic data for this hour is the only data analyzed in engineering the network. But many switch components will have a different average peak usage hour; the same components may also have levels of traffic significantly different during their actual peak usage hour. This results in overburdened or under used switch components that may fail or be more expensive to operate.
Also, the average peak usage hour normally is determined only once a year. This was fine, in the past, when the relative stability of traffic usage across switches required determination of the average peak usage hour only yearly in order to support traffic engineering. The network equipment and customer assignment procedures used when prior traffic usage processes and systems were developed resulted in relatively homogeneous traffic usage across switch components, which also allowed infrequent selection of an average peak usage hour.
Recently, however, numerous changes in technology and the industry have occurred. Those changes have drastically and negatively impacted the effectiveness of current processes in analyzing switching capacities.
For instance, two separate causes have resulted in non-homogenous assignment on switch components. First, subscriber carrier delivery systems have reduced the random spreading of the customer assignment process. Most subscriber carrier systems typically handle about 96 lines each and serve a very small geographic area. Because of this, systems often serve primarily only residential customers or only business customers. For example, new subdivisions may have all of the residences therein assigned to a new switch component. Thus, a switch component handling customers located in a high-end residential area with many second lines and computer modems may handle significantly more and different traffic than components of the rest of the switch. Customers with different usage characteristics are concentrated on different switch components, leading to wildly different busy hours among the components.
A second reason for increasingly non-homogenous assignment is the practice of reusing previously assigned facilities when service to a new customer at an old location was introduced (e.g., when an old customer moves, the connection to the residence remains and service is simply restored when someone else reoccupies the residence). That significantly reduces labor associated with establishing new service at previously occupied locations, but results in less homogeneous traffic because new customers end up being served in a specific, new switch component.
Finally, there has been a constant and increasing proliferation of high use lines for internet service providers, telecommuting host computer connections, and the like. These new, numerous and high use lines also have increased the traffic load differences between various switch components.
Overall, these changes have reduced the homogeneous nature of the traffic load across switch components. Growing numbers of switch components accordingly have average peak usage hours that are different from the average peak usage hour for the whole switch and other components. Also, not only are the average peak usage hours different among components, but the "peak" traffic handled by a particular component may be significantly different from the "peak" traffic handled by other components or the entire switch. This is especially exacerbated by grouping of new subscribers, who may use newer technologies, onto a single switch component, as described above.
Numerous components are accordingly not being engineered for proper traffic load. Further, rapid growth in telecommunications has resulted in dynamically changing average peak usage hours. For example, as businesses increasingly provide internet access for their employees, switch traffic during the previously little used lunch hour has greatly increased as employees make use of a "free" internet connection during lunch breaks.
In short, there is a need for traffic analysis systems and processes that dynamically respond to changes in average peak usage hour and that take account of loads across switch components when analyzing traffic usage. That information is then used to (a) adjust the load on a particular switch or its components or (b) reengineer the network to a more optimal configuration for its actual load.